HW5 (due Monday, Nov 12, midnight)
----------------------------------

In this homework you will complete the definintions of both a
polymorphic type checker and a polymorphic type inferencer for FUN.
The type checker has been defined in the lecture notes.  The type
inferencer has not, but Milner's W procedure has been defined in the
lecture notes and our type inferencer extends that one.

The root directory contains all the language definitions that we
discussed so far in class.  Those of you doing a project, or simply
interested in defining their own language, may find the various
language definitions useful.  It may be instructive to take a look in
the k-prelude.maude which is located in the root directory.
Suggestions on how to simplify it are welcome.  Note that the
strictness modules are all generated automatically in all our
definitions.  I already generated them for you, so you don't need to
worry about it for the HW.  If you are interested in doing it, though,
then you should first load the syntax module of your language
containing a module called LANG-SYNTAX, then load the k-prelude,
then type red makeStrict("LANG").  That would generate the strictness
module as a string, with "\n" for expected new lines; you need to
replace all those with new lines (in XEmacs, you can do it by
replacing globally each "\n" by "Crtl-q Crtl-j").

Problem 1 (15 points)
---------------------

Complete the definition in file
FUN/polymorphic-type-checking/fun-type-checking-semantics.maude.
To test it, just go into that directory and run maude on that file.
It already includes everything you need.

Problem 2 (5 points)
--------------------

The last two programs (p19 and p20) show two standard problems with
polymorphic type checking.  Ellaborate on these problems (showing that
you understand them) and propose solutions (without formally defining
them, just use words!).  Also, note that, unlike any other expression
in, the empty lists need to be annotated with their type.  Is that
needed?  Can we avoid it?  At what price?

Problem 3 (15 points)
---------------------

Same like Problem 1, but for the file
FUN/polymorphic-type-inference/fun-type-inference-semantics.maude.

Problem 4 (5 points)
--------------------

Note that p19 can be properly infered its polymorphic type.  How is
that possible, considering that, as we saw in Problem 2, the type
checker could not properly calculate its polymorphic type?  Why should
a type inferencer/checker reject programs like p20?  How would we
change our definition to do it?  (you don't need to actually change
the Maude definition, just say it in words! we deliberately accept
this "bug" in our definition - BTW, this is called "weak polymorphism"
and is a hot/tricky topic in PL research)
